Packet processing engines need to have some way to bring a packet into the system for processing. There have conventionally been a number of alternatives ways of accomplishing this, the choice often depending on the throughput required.
One of the simplest way is by copying a packet into memory and providing a pointer to that packet in memory to a general-purpose processor. The processor software or computer code would then operate on the packet while in memory. This approach typically works only for low-performance systems, such as systems having throughput requirements less than about 100 Megabits per second. FIG. 1 is a diagrammatic illustration showing an example using a general-purpose processor. General Purpose Processor 100, Packet Source/Sink 140, and Memory 120 are all connected to and communicate with each other via Main bus 150. Packets arrive and are sent via Packet Source/Sink 140, and are stored in Memory 120. A register 110 inside General Purpose Processor 100 contains the address of a Packet 130 in Memory 120.
For higher performance, one may dedicate some specific logic for processing the packet contents at higher speed, such as an accelerator to and under the control of a general-purpose processor. While this can increase the speed of the actual packet processing, the general-purpose processor may usually still remain a bottleneck and limit packet throughput. FIG. 2 illustrates General Purpose Processor 200, Packet Source/Sink 240, Memory 220, and Packet Processing Offload 250 all connected by and intercommunicating via Main bus 260. Packet 230 in memory is sent to Packet Processing Offload 250 for higher-speed processing, under the control of General Purpose Processor 200.
One possible partial solution for obtaining greater performance might be obtained by having the traffic come directly into Accelerator 250 so that packets can be processed directly. Only occasional “exception” packets would be sent to the general-purpose processor. Exceptions, might for example arise when management packets are sent. Management packets do not normally contain network traffic, but rather contain instructions for changing network characteristics, or requests for network information. This for example is shown in FIG. 3, where Packet Source/Sink 310 is directly connected to Packet Processing Fast Path 320 without having to traverse Main bus 330 or be processed by General Purpose Processor 300.
There are two ways to provide access to the packet data for the fast path. One is to treat the packet as a stream, and have the stream of data run through the fast path, as shown in FIG. 4. Here packet data going to and from Packet Source/Sink 410 is sent in streams, arriving into the Packet Processing Fast Path 420 on stream 440 and leaving Packet Processing Fast Path 420 via stream 450. However, many applications only require operations on a small portion of the entire packet, so that having to move the entire packet hampers throughput.
FIG. 5 describes an alternative to the above described system and approach. Here full packet 540 is broken into two portions: a first portion 570 that will affect computation, and a second portion 560 that will not affect computation. The first portion 570 streams through Packet Processing Fast Path 520; the second portion 560 is stored in Memory 500. The first portion, when combined with other optional data such as a pointer to the second portion 560 in memory, a context size, and other such optional information, may be referred to as the “context.” The second portion 560 may conveniently be referred to as the “payload”, even though it may or may not constitute the entire actual payload, or may include more than the actual payload. The portion of the context that was severed from the payload prior to entering the fast path must be rejoined with the payload before the packet is sent on or forwarded to the next destination. FIG. 5 shows an exiting context 580 and payload 590 being rejoined into full packet 550 when being sent back to Packet Source/Sink 510.
One conventional approach illustrated and described relative to the configuration of FIG. 6 is to use a Media Switch Fabric (MSF) circuit or similar circuit. FIG. 6 shows Packet Processing Fast Path 600, being fed by Packet Source/Sink 610. MSF 640 takes the packets and sends the context to Computing Resources 630 via connection 660, and sends the payload portion to Memory 620 via connection 670. Exiting packets are rejoined in MSF 640 by combining the context that arrives on connection 650 with the payload retrieved from Memory 620 on connection 670. The functioning of MSF 640 is controlled by the Computing Resources 630; the computation determines which packets to intercept, how to divide and route the bits internally, and any other operations performed by MSF 640. One downside or disadvantage to this approach is that computational resources are required for this, making less processing or computing power available for the actual packet processing algorithms.
In light of these problems and limitations on conventional systems and methods, it will be apparent that there remains a need for a system, device, and method that provides a system for receiving, transmitting, and managing packetized data that has a high-throughput and does not consume computational or processing resources that may better be utilized for actual packet processing.